On Mon, Dec 19, 2016 at 2:07 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi Moray,

A dedicated Thread for messaging might be one approach.  But you should be able to handle messages in the same Thread just make sure you do everything in a non blocking manner.  Using less Threads is more CPU efficient, can avoid multi-Thread communication issues, and avoids the issue of getting multiple Threads started.

So for example you might implement a message queue that code can instantly insert messages into.  Then inside your system monitor loop include a call to a ServiceMessageQueue() Function.  This function would be somewhat state driven. 

The first state would be waiting for a message in the queue and that KMotionCNC is available to receive a command.  If so it would extract the message and send it (without waiting for acknowledgement), then transition to the next state.

The next state would check for the acknowledgement, and if acknowledged, transition back to the first state.

A more specific example of what you are trying to do would be helpful.

Regards

TK

On 12/17/2016 1:38 PM, Moray Cuthill moray.cuthill@... [DynoMotion] wrote:

 

This is something I know is still an issue on my lathe, but I want to come up with some strategy to avoid it on my new mill.

My current thought is to start a second thread, that has the sole purpose of displaying messages, and won't matter if the thread gets blocked.

The main init thread simply sets a flag (probably use a uservar with a value set for each possible message), and carries on it's usual business of monitoring everything, while the second thread monitors for the flags and displays messages as required. I can see the need to implement some method to ensure message requests don't get overwritten before they've actually been displayed.

It will probably mean implementing some state machines for anything that may require a user response, but it would avoid a message blocking execution of the system monitoring.

Does this sound reasonable?

If so, what would be the best way of executing two threads at the same time?

Two separate buttons in KMotionCNC, with some checking to make sure they've been pressed in the correct order?

Flash one to the KFlop, and use the startThread() option, with some form of interaction during initialisation to make sure the thread is there and started?

Thanks,

Moray

On Mon, Dec 19, 2016 at 8:43 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

[Attachment(s) from Tom Kerekes included below]

Hi Moray,

The printf functionality should not be blocked while a message is displayed.  Rather your monitor loop is blocked waiting for the message response.

Unfortunately the standard MsgBox functions block waiting for the response.  I've coded up new separate routines MsgBoxNoWait and MsgBoxGetResponse that will not block and allow you to poll until a response is received.   I've attached the additional functions and an example of how to use it.

Let me know how much of this makes sense.

Regards

TK

On 12/19/2016 2:14 AM, Moray Cuthill moray.cuthill@... [DynoMotion] wrote:

 

Hi Tom,

as it stands with my lathe, I have an estop_test monitor function (it get's called continually by the main init loop), which monitors for the various estop conditions, if one occurs, it sets a message flag, handles the estop, then displays the message.

However once the message gets displayed, any printf statements from elsewhere in the main init loop stop, until the message has been acknowledged.

Am I correct in assuming that because the printf stream to the console has stopped, that the thread is currently blocked? Or is it simply the communication between the KFlop and the PC that's blocked?

I've got a printf that displays the Modbus status/tool change positions every few seconds, and they certainly stop for the duration a message is displayed, and they don't seem to get buffered.

I've attached an older copy of the estop file (only difference I'm aware of is it lacks break statements in the message switch), along with the header file, but the constant/enum names should be self explanatory.

For my mill, I'd like to make things a bit more robust, and then work the required changes into the lathe, so the machines use a similar code structure.

The mill will also have the added complexity of the KFlop controlling the ATC directly, as the lathe uses a PLC controlled via Modbus.

Moray

On Mon, Dec 19, 2016 at 2:07 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi Moray,

A dedicated Thread for messaging might be one approach.  But you should be able to handle messages in the same Thread just make sure you do everything in a non blocking manner.  Using less Threads is more CPU efficient, can avoid multi-Thread communication issues, and avoids the issue of getting multiple Threads started.

So for example you might implement a message queue that code can instantly insert messages into.  Then inside your system monitor loop include a call to a ServiceMessageQueue() Function.  This function would be somewhat state driven. 

The first state would be waiting for a message in the queue and that KMotionCNC is available to receive a command.  If so it would extract the message and send it (without waiting for acknowledgement), then transition to the next state.

The next state would check for the acknowledgement, and if acknowledged, transition back to the first state.

A more specific example of what you are trying to do would be helpful.

Regards

TK

On 12/17/2016 1:38 PM, Moray Cuthill moray.cuthill@... [DynoMotion] wrote:

 

This is something I know is still an issue on my lathe, but I want to come up with some strategy to avoid it on my new mill.

My current thought is to start a second thread, that has the sole purpose of displaying messages, and won't matter if the thread gets blocked.

The main init thread simply sets a flag (probably use a uservar with a value set for each possible message), and carries on it's usual business of monitoring everything, while the second thread monitors for the flags and displays messages as required. I can see the need to implement some method to ensure message requests don't get overwritten before they've actually been displayed.

It will probably mean implementing some state machines for anything that may require a user response, but it would avoid a message blocking execution of the system monitoring.

Does this sound reasonable?

If so, what would be the best way of executing two threads at the same time?

Two separate buttons in KMotionCNC, with some checking to make sure they've been pressed in the correct order?

Flash one to the KFlop, and use the startThread() option, with some form of interaction during initialisation to make sure the thread is there and started?

Thanks,

Moray